Organizations typically have multiple platform dependent and language (e.g., Java™, C++, .Net, etc.) dependent solutions to support various portions of their business and operation. For example, an organization may use Java™ to create a web-based solution to support the organization's e-commerce operation, and may purchase a .Net solution to support customer relationship management (CRM). If the organization wishes to integrate the two solutions, a “bridge” is required. The bridge, in this particular example, allows the .Net based CRM solution to interact with the Java™ based web-solution and vice versa.
There are three main categories of bridges: local, remote, and distributed. A local bridge is one, which will result in bridging two bodies of code existing in the same process (e.g., within the same application). A remote bridge is one, which will result in bridging two bodies of code existing in multiple processes (e.g., different application spaces). In the local bridge and the remote bridge solutions, portions of the bridge components will exist in both the bodies of code being bridged. In contrast, each component in a distributed bridge resides in a separate process, i.e., two bodies of code each exist in a separate process, and the bridge also resides in a separate process.
An example of a bridge technology that is currently available is the Java™ Native Interface (JNI). JNI is a model for bridging code based on the ‘C’ language standard. In the following descriptions of bridge architectures, the client code is that body of code attempting access to existing code, the target code is that pre-existing body of code which exists as an application or library. The following describes the typical steps involved in implementing a JNI-based solution for bridging a Java™-based application with Native ‘C’ code. First, the Java™-based application is created exposing native methods, i.e., methods implemented in ‘C’. This is done by qualifying a method with the “native” keyword. The Java™-based application is compiled typically using “javac”. The “javah” command with the -jni flag is then used to generate a ‘C’-style header file containing method declarations for each method declared as “native.” Using the generated ‘C’-style header file, an implementation file is created containing an implementation function for each declared method in the ‘C’-style header file. The implementation file is then compiled creating a native dynamic library. Additional Java™ code is then added to the Java™-based application to load the new dynamic library prior to the use of the native methods. The Java™-application is then re-compiled to produce the Java™-based application. Prior to running the Java™-based application, any changes to the environment to allow the dynamic library to be locatable and loadable are also performed. Once this is complete, the Java™-based application may be run. If the native code was re-written in C++, the above mentioned steps would have to be repeated to create a new bridge.